Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix nested super type modifier handling #705

Merged
merged 2 commits into from
Aug 27, 2024
Merged

Fix nested super type modifier handling #705

merged 2 commits into from
Aug 27, 2024

Conversation

greg-rychlewski
Copy link
Member

@greg-rychlewski greg-rychlewski commented Aug 26, 2024 •
edited
Loading

Closes #704

The issue is with nested super types we may pass {extension, modifier} down so we end up with {{extension, modifier}, nil}.

We want to flatten it out and pass nil for the range modifier because we don't know how the Postgres modifier for ranges works yet. Passing nil will have it default to what it was before we started handling modifiers.

@greg-rychlewski greg-rychlewski changed the title Fix nestes super type modifier handling Fix nested super type modifier handling Aug 26, 2024
@greg-rychlewski greg-rychlewski mentioned this pull request Aug 26, 2024
Closed
@greg-rychlewski
Copy link
Member Author

I don't think this is the right solution actually. Since it happens with list of length 2 instead of 1 we are not unpacking the type somewhere we should be....will keep looking.

@jdav-dev
Copy link

I can't say whether or not this is the right solution, but this branch does work for my script from #704.

@greg-rychlewski
Copy link
Member Author

This one was a doozy. We cannot modify the variable type in the extensions otherwise when you have an array of super types it will pass the modified sub-type to the next member of the array. So I made it a more explicit name that shouldn't conflict.

@jdav-dev
Copy link

This one was a doozy. We cannot modify the variable type in the extensions otherwise when you have an array of super types it will pass the modified sub-type to the next member of the array. So I made it a more explicit name that shouldn't conflict.

I just came to the same conclusion. This is the actual issue!

@greg-rychlewski greg-rychlewski merged commit 5924c18 into elixir-ecto:master Aug 27, 2024
9 checks passed
@greg-rychlewski greg-rychlewski deleted the range_fix branch August 27, 2024 10:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@jdav-dev jdav-dev jdav-dev left review comments

@josevalim josevalim josevalim approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Arrays of custom timerange types with more than one element worked in 0.18, do not work in 0.19
3 participants
@greg-rychlewski @jdav-dev @josevalim